Pull request overview

This PR introduces a grails-jacoco Gradle convention plugin and corresponding GitHub Actions workflow to enable code coverage reporting and Codecov uploads. It's carved out from a larger Hibernate 7 work stream, depends on PR-G (grails-code-analysis), and is intended to be re-targeted at 8.0.x after that PR merges.

Changes:

• New GrailsJacocoPlugin build-logic convention plugin (with TestKit specs) that configures per-project JaCoCo and lazily registers a root jacocoAggregateReport task, excluding hibernate7 source/class dirs to avoid duplicate-class errors while still aggregating their exec data.
• Applies the new plugin alongside grails-code-style and grails-code-analysis in ~84 subproject build.gradle files (single-line plugin additions).
• Adds .github/workflows/coverage.yml running jacocoAggregateReport for grails-core and the nested grails-gradle build across a 3-OS matrix, then uploads the artifacts to Codecov.

Reviewed changes

Copilot reviewed 100 out of 100 changed files in this pull request and generated 1 comment.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

📊 Pull Request Review Summary

This is an excellent, high-impact addition to the build ecosystem. Introducing a unified grails-jacoco convention plugin establishes a consistent, localized footprint across the multi-project architecture while ensuring test execution results aggregate cleanly into a single target for accurate upstream Codecov coverage processing.

🛠️ Core Build & Logic Analysis

🔌 GrailsJacocoPlugin.groovy

• Idempotent Root Registration: Dynamically registering the jacocoAggregateReport task on the rootProject via the subproject plugin application is a great approach. Checking root.tasks.names.contains(AGGREGATE_TASK_NAME) keeps the lifecycle safe and dynamic as subprojects configure.
• Variant Class Deduplication: The exclusion filter on line 109 (if (!project.path.contains('hibernate7'))) is crucial. Because the Hibernate 7 variant subprojects output identical class names to the primary Hibernate 5 modules, bailing out of source/class directory aggregation for H7 blocks the dreaded JaCoCo Can't add different class with same name exception.
• Execution Data Integrity: Crucially, even though H7 classes are excluded from the report metrics to prevent duplicates, line 99 still correctly captures their .exec data output (project.fileTree(...)). This ensures coverage driven during the Hibernate 7 suite runs is accurately credited back to the primary class definitions.

🧪 Test Harness (GrailsJacocoPluginSpec.groovy)

• The integration coverage utilizing Gradle's GradleRunner is solid. Testing both the configuration presence (jacocoTestReport task matching) and the explicit multi-project task dependencies (:app-module:test in dry-runs) gives great baseline confidence that refactors won't break the aggregation behavior.

⚙️ CI Pipeline Configuration (coverage.yml)

• Open Source Cache Alignment: Explicitly pinning cache-provider: basic inside gradle/actions/setup-gradle is an excellent configuration choice. Utilizing the basic provider honors the core open-source lifecycle, avoiding the proprietary, commercial terms of use attached to the default enhanced provider in version 6+.
• Partial Upload Resilience: Setting if: always() on the upload-coverage job guarantees that even if individual test suites or OS matrix blocks time out or experience independent tool failures, the coverage metrics captured up to that point are still packaged and piped over to Codecov.

💡 Architectural Recommendation / Improvement

Inside GrailsJacocoPlugin.groovy (lines 97–102), the execution data configuration is currently mapped via a dynamic task configuration block inside contributeToRootAggregateReport:

aggregateTask.configure { JacocoReport task ->
    task.dependsOn project.tasks.withType(Test)
    task.executionData.from(
        project.fileTree(project.file('build/jacoco')) { include '*.exec' }
    )
}

The Opportunity: Since this plugin is meant to be applied globally across all code modules, we can harden this dependency wiring against unexpected build layout variations by hooking directly into the output providers of the individual Test tasks.

Instead of hardcoding a file tree string path search for build/jacoco/*.exec (which can occasionally experience evaluation timing race conditions if a submodule overrides its standard layout directory structure), you can bind directly to the task providers.

Updating that configuration block to leverage provider mapping safely maps execution dependencies lazily:

aggregateTask.configure { JacocoReport task ->
    project.tasks.withType(Test).configureEach { Test testTask ->
        task.dependsOn(testTask)
        // Dynamically binds to the precise runtime execution data location of the test task instance
        task.executionData.from(testTask.extensions.getByType(JacocoTaskExtension).destinationFile)
    }
}